Fix library search matching interface control text#47
Conversation
The homepage search built its per-row haystack from the entire row's textContent, which includes the "Copy loop" action button and the JavaScript-injected "Show more"/"Show less" prompt toggle. As a result, typing copy, show, more, or less matched every loop instead of filtering. Snapshot each row's searchable text once at load from the .cell-loop content (category, attribution, title, summary, and prompt) before the toggle button is inserted, and reuse that cached value when filtering. This keeps title/prompt/keyword search intact while excluding interface controls, and avoids re-reading textContent on every keystroke.
|
Thanks for building Loop Library — the agent-native framing and the care in the catalog really show. This one's a small, self-contained fix. The homepage search built its haystack from each row's full I followed AGENTS.md — |
mberman84
left a comment
mberman84
left a comment
There was a problem hiding this comment.
The search-indexing change itself is correct and passed the integrated checks/browser verification. One deployment blocker remains: this changes site/script.js without changing the versioned script URL currently referenced as ?v=20260620-newest-first.
The live asset is cacheable for an hour with stale-while-revalidate, so existing visitors can continue receiving the old search behavior after deployment. Please bump the shared script asset version everywhere it is emitted and validated, including the generated loop-page template and scripts/check.mjs, then regenerate affected pages.
Per review: site/script.js changed without bumping the versioned asset URL (?v=20260620-primary-nav), so visitors holding the hour-cacheable, stale-while-revalidate asset could keep running the old search behavior. Bump the shared script.js version to 20260621-search-index across the homepage, Learn and Agents pages, the loop-page generator, and the scripts/check.mjs assertions, then regenerate the loop detail pages.
|
Thanks — good catch on the cache angle. Bumped the shared |
|
@mberman84 this is ready for another look whenever you have a moment — the asset version is bumped and the loop pages regenerated. Thanks for the careful review! |
2 participants
Summary
The homepage library search matched interface control text, so several common words filtered nothing.
updateLibrary()built each row's search haystack from the entire row'stextContent:A loop row's
textContentincludes the "Copy loop" action button, and — afterscript.jsruns — the injected "Show more" / "Show less" prompt toggle. Because every row contains those strings, typingcopy,show,more, orlessmatched all loops instead of filtering them.Fix
Snapshot each row's searchable text once at load, reading the
.cell-loopcontent (category, attribution, title, summary, and prompt) before the prompt toggle button is inserted. The cached, pre-normalized value is then reused on every keystroke.This:
.cell-action"Copy loop" button and the injected toggle from the search index,data-searchkeyword matching fully intact, andtextContentfor all rows on every keystroke.Verification
copyorshow→ all 44 loops shown. After: those words match only loops whose content actually contains them.node scripts/check.mjs→Loop Library checks passed.node --check site/script.jsnode scripts/build-skill-catalog.mjs && node scripts/build-loop-pages.mjs && node scripts/build-social-images.mjs→ no artifact drift (git statusclean apart fromsite/script.js).npm --prefix worker run check→ tests pass.